The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In order to access a network such as the Internet a user device such as a personal computer (PC), set top box or Voice Over Internet Protocol (VoIP) telephone typically obtains access through customer premises equipment (CPE). One or more CPE's communicate with a gateway to the network such as an aggregation device in the form of a broadband remote access server (BRAS). The aggregation device obtains and applies a policy to communication between the user device and the Internet ensuring for example that the user device is authorised, that an appropriate quality of service (QoS) such as bandwidth is applied and that an appropriate billing method is applied.
Typical operation can be further understood with reference to FIG. 1 which is a high level diagram illustrating a network of the type described above. A first user device 100 initiates a data session with a first remote destination device 102 which can for example be a remote host or service reachable via the Internet designated generally 104. The data session can be any appropriate data session such as a transmission control protocol (TCP) connection including, as a source identifier, a source IP address of the user device 100 and as destination identifier the IP address of the remote entity 102, and the data session is designated generally 106.
The user device 100 communicates with services on the Internet provided on remote device 102 via a CPE device 108 which in turn communicates with an aggregation device 110 which in turn communicate with further aggregation devices and/or Internet core devices. The aggregation device 110 communicates with a management device or portal such as a subscriber edge service manager (SESM) 112 which returns user device information which can be used by the aggregation device to then obtain the associated policy from a policy server such as an authorization, authentication and accounting (AAA) server 114. This is handled during a service session between the user device 100 and the aggregation device 110 which, once set up, allows the user device 100 to carry out multiple data sessions, for example a further data session with a second remote device 116.
FIG. 2 shows aspects of a typical data session packet corresponding to traffic within a TCP connection. The packet includes in its header a source identifier field 200 with a source device identifier such as the user device 100 IP address. In field 202 a data session identifier comprises for example a native data session identifier such as the TCP source port. Field 204 comprises the IP address of the remote device 102 as destination address. Field 206 similarly identifies the TCP destination port and field 208 carries the data or payload associated with the packet.
Where a CPE serves a single user device then management of a session can be further understood with reference to FIG. 3 which is a flow diagram illustrating the steps involved in initiating communication between a user device 100 and a remote device 102. Initially at step 300 the user device subscribes with the service aggregation device and a data session control identifier such as a user name is assigned or selected for the user, an associated service session control function such as an appropriate policy being stored against the user name in the AAA server.
At step 302 the user device 100 initiates an explicit service session with the aggregation device 110. This can occur, for example, when a user logs on to the user device and requests Internet access. At step 304 the aggregation device 110 needs to retrieve the data session control identifier associated with the user. In particular the aggregation device receives limited information from the user device identifying it, namely the source device IP address. As mentioned above, in order to obtain the policy for the user device, however, the user name is required as data session control identifier. Hence the aggregation device at step 304, sends the source address to the management device 112.
One known approach for this step is described in U.S. Pat. No. 6,983,332 of Lou et al., “Port-bundle host-key mechanism,” commonly assigned herewith and incorporated herein by reference for all purposes as if fully set forth herein. According to the approach described in Lou et al., where an aggregation device handles multiple CPEs there is a risk of reuse of a common IP address, use of a non-recognised local address space between the aggregation device and the portal or of multiple aggregation devices communicating with a portal. Lou et al. addresses these issues by replacing the source port number and source port address with an aggregation device assigned port number and address associated with the CPE source address. The replacement port number and source address are sent to the management device which maintains a table and returns the correct user name.
Reverting to FIG. 3, at step 306 the management device returns a data session control identifier recognizable by the AAA server such as a user name and at step 308 the aggregation device sends the user name to the AAA server. At step 310 the AAA server retrieves the policy associated with the user name for service session control and returns this to the aggregation device. At step 312 the aggregation device 110 applies the policy to the service session permitting data sessions between the user device and remote entities.
In most instances the CPE 108 serves a plurality of user devices 100, 118, 120 forming a community of source devices 122. In this case it is known for the CPE to act as a community translation service device. In particular because a local address space may be introduced between the CPE and the community 122 of devices, the addresses may not be recognizable to external devices as the aggregation device 110. In particular, as can be seen with reference to FIG. 4 which is a translation table implemented by the CPE and FIG. 5 which is a flow diagram illustrating translation steps performed by the CPE, the CPE swaps the user device source address for a CPE assigned translated source identifier which acts as an “overloaded” IP address serving multiple user devices.
In particular at step 500 the user device initiates a service session with its IP address as source identifier and a native data session identifier such as a TCP source port as data session identifier. At step 502 the CPE translates the source address to its own overloaded IP address. At step 504 the CPE additionally translates the TCP source port to its own TCP port in a Port Address Translation (PAT) step as described in more detail below. Then, as step 506, the CPE forwards returning traffic with the translated overloaded IP address and TCP port to the user device, reinstating the user device IP address as destination address and the user device assigned TCP port number.
A corresponding assignment scheme can be understood with reference to FIG. 4. Where, for example, the first user device 100 initiates a data session with the first remote device 102 it will use its IP address as source address and will also assign a TCP source port number, for example 1024. If a second user device 118 initiates a data session then it will similarly assign its IP address as source address and its own TCP source port which may be the same as that assigned by the first user device, as the session is between different entities. As a result both user devices 100 and 118 may have individual TCP connections with a first remote device 102 using different source addresses but the same TCP port. In a similar manner the respective user devices 100, 118 may also set up TCP connections with a second remote device 116 again with their respective source addresses but with the same TCP port 1025 assigned. As discussed above, the CPE 108 will replace the source address with its own overloaded IP address. In addition, however, in order to be able to distinguish the data sessions it will replace the natively assigned data session identifier, that is the TCP source port, with an assigned data session identifier such as a TCP port number pulled from a pool of available, non-assigned port numbers.
Referring to FIG. 4, therefore, it will be seen that where a data session has an input TCP port 1024 (column 402) and an input source address (column 404) of IP1 (for the first user device 100 connecting to the first remote device 102) and another data session has a TCP port 1024 and IP2 (for the second user device 118) then the CPE will assign an output port (column 406), say 1101, 1034 respectively corresponding to the connection and having an output source address (column 408) comprising the CPE address IPCPE. For purposes of clarity the corresponding connection is shown in column 400. Further connections between the first and second user device and second remote device 116 are shown with CPE assigned TCP port numbers 1042, 1106.
This approach is known as port address translation (PAT) and it will be seen that PAT obscures the identity of the host or user device. As a result where the IP addresses of multiple user devices such as PC's are translated to a single, overloaded IP address, with source ports assigned on a first-come-first-served basis across the connected PC's, it is not possible for a provider edge device such as an aggregation device to classify incoming packets as belonging to a particular host or user device without additional information being provided, typically through the application layer, for example through the use of HTTP cookies.
Hence the aggregation device must apply a common policy for all user devices within the community 122 served by the CPE 108. However this can give rise to various problems. Where the community comprises, for example, a domestic residence with multiple PC's used by different family members then it may be desirable to apply different policies to the different devices in order to exert parental control on content. Furthermore different devices may wish to use different ISP's. A further problem arises in the case of “triple play” where respective user devices comprise a PC having a data connection, a set top box requiring media content and a VoIP telephone requiring low latency connectivity. In addition or alternatively a security camera may have Internet connectivity. In that case it can be seen that different policies need to be applied for each device. More generally, additional flexibility is required in the application of policies to multiple user devices in a common community.